<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title></title>
<meta name="GENERATOR" content="Microsoft Visual Studio .NET 7.1">
<meta name=ProgId content=VisualStudio.HTML>
<meta name=Originator content="Microsoft Visual Studio .NET 7.1">
</head>
<body>
<!-- Begin Common Doc (Swaf.Gui.Abstract) -->
		<P class="MsoNormal">The GUI portion of the framework breaks down an application UI 
			into various elements that supports very flexible deployment options. A key 
			aspect of the GUI framework is to support a single design model across several 
			different UI libraries such as .NET windows forms or IE DHTML and to do it in a 
			way that supports key OO design principles. Through this framework it is 
			possible to build much of the client tier code once, but have it work with 
			multiple UI libraries for ultimate flexibility in deployment.</P>
		<H2>Abstract</H2>
		<P class="MsoNormal">The functionality of the UI is broken down into a set of 
			relationships that clearly define responsibilities and is somewhat similar to 
			the Model View Controller (MVC) design pattern. The framework takes the MVC 
			pattern and goes several steps further in refinement. At the core of the GUI 
			framework are three interfaces; IGuiWidget, IBusinessProcess, and IView.
		</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal"><IMG height="323" src="Swaf.Gui.Full_files/image001.gif" width="324"></P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">An IGuiWidget implementation is a UI element that has a 
			specific set of functionality. Examples of GUI widgets are customer display, 
			customer list display, etc., and are somewhat similar to a view in the MVC. An 
			IGuiWidget isnt simply a control from the OS like the text box or list box. It 
			usually is a higher level abstraction that uses low level controls to build 
			itself. One of the key responsibilities of a GUI widget is to act as the bridge 
			between a high level UI business abstraction like customer display and the 
			details of the GUI library it is targeted for such as .NET win forms or Java 
			swing. As such a specific implementation of IGuiWidget is tightly coupled to a 
			specific GUI library.
		</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">For example, the UI abstract ICustomerDisplay interface has 
			methods to display a customer and events that indicate the user has changed 
			the customer in some way. This is all that is needed to be known about the 
			customer display in order to be useful to a business process implementation. 
			A specific implementation of the ICustomerDisplay could use a .NET windows user 
			control, text boxes, and other .NET controls to display a customer. Another 
			implementation could use DHTML with tables, forms, and other HTML elements. Yet 
			another could use MS Outlook specific mechanisms. Each implementation is tied 
			to a specific kind of hosting environment.</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">An IBusinessProcess implementation exposes some number of 
			application use cases that require a user interface and interaction with a real 
			person. It uses a collection of GUI widgets to interact with the user, listens 
			to high level events from the widgets and calls business rules in response to 
			user activity. This is somewhat similar to the controller in the MVC. GUI 
			widgets handle all of the low level events that are triggered in its 
			implementation in order to manage itself. They generate high level events that 
			represent real user activity.
		</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">In general, a widget wouldnt expose things like key presses 
			and mouse clicks, but rather generate events such as business object selected 
			or business object changed. This helps ensure a solid abstraction between a 
			GUI widget and a business process, which makes it simple to switch to radically 
			different GUI widget implementations without changing the business process 
			itself. When a GUI widget exposes low level events, it helps to couple the 
			business process to itself because it forces the business process to understand 
			the fundamental workings of the GUI widget, which should be of no concern to 
			it.</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">The implementation of IBusinessProcess is critical business 
			logic to the application and great care should be given to keeping it at a very 
			specific level of abstraction and to be as decoupled from technologies as 
			reasonably possible. Ultimately it provides the business behavior of how a 
			system should interact with a user at a specific level of abstraction not too 
			wide or too deep. A business process that is too wide if its implementation 
			takes on more business functionality then it should, which ultimately 
			intermixes the code of the different business uses cases.
		</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">A business process that is too deep in its implementation 
			takes on too much of the details of the specifics of how to interact with the 
			user, which is the domain of the GUI widget. A wide business process can be 
			thinned out by building two or more business processes in its place. A deep 
			business process can be made shallow by pushing GUI details into GUI widgets. 
			However, there are limits to how thin or shallow a business process should be.</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">An IView implementation exposes some number of business 
			processes and their corresponding widgets directly to the user. A view 
			represents the specific mix of business processes and how their GUI widgets 
			should be laid out as a presentation to the user. The specific business 
			processes, how they are connected to interact with each other, and how their 
			widgets are arranged on the screen makes one view unique from other views in 
			the application. View implementations are typically tightly coupled to the 
			hosting environment they are created in. The hosting environment is the 
			executable application that provides the window frame, and overall execution. 
			Examples of a hosting environment include:</P>
		<UL style="MARGIN-TOP: 0in" type="disc">
			<LI class="MsoNormal">
			A regular .NET win form application.
			<LI class="MsoNormal">
			Internet explorer running a web page.
			<LI class="MsoNormal">
			Outlook, Word, and Excel documents.
			<LI class="MsoNormal">
				ASP.NET server-side web ASP processing.
			</LI>
		</UL>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">If an application hard-coding the view implementations 
			responsibilities into a windows forms class, it wouldnt be able to run in 
			other operating environments and take advantage of the environment.</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">It isnt practical to decouple a view implementation from the 
			specific hosting environment it is contained in because a portion of the views 
			responsibilities is to help expose the features of the hosting environment to 
			the application. For example, when using some business process in internet 
			explorer, menu commands might best be exposed as DHTML menus. When hosting in a 
			windows forms application, the menu of the form itself could be used to more 
			tightly integrate into the form itself. The same holds true for the status bar 
			and other native widgets of the hosting environment.</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">When hosting in an Outlook environment, there are lots of 
			unique features and capabilities that could be exposed to the application in 
			ways that keep the overall application loosely coupled from them yet still 
			allow deep integration when available.</P>
		<H3>Secondary Abstracts</H3>
		<P class="MsoNormal">The IView, IBusinessProcess, and IGuiWidget interfaces are not 
			enough to build robust applications. They rely on several supporting interfaces 
			as well as the BizRule and BizObj namespaces to provide a complete environment 
			for serious GUI development. Within the GUI namespace there are several other 
			interfaces that round out the abstraction including the ILayoutManager, 
			IAction, ICommand, ICommandList, IViewHandler, and ILayoutTemplateHandler.</P>
		<P class="MsoNormal"><IMG height="500" src="Swaf.Gui.Full_files/image002.gif" width="552"></P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">A fundamental abstraction in the GUI namespace is the 
			IGuiElement interface which serves to unify the various elements in the 
			namespace similar to how the Object class works in both .NET and Java.</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">Business processes expose a collection of IAction objects that 
			provide ways to trigger fundamental actions that it defines. IAction has a set 
			of properties that describe the action, and methods to call the action to 
			trigger the business process behavior.
		</P>
		<P class="MsoNormal">
		</P>
		<P class="MsoNormal">Typically the view is responsible for mapping business process 
			actions to UI controls that are able to expose them to the user. Specialized 
			IGuiWidget classes that implement ICommandListDisplay are designed to have a 
			set of commands defined that map to actions. These widgets can display the 
			commands directly to the user in a way they need, such as using a windows form 
			main menu, context menus, toolbars, DHTML mechanisms and so forth. The view is 
			responsible for making these mappings.</P>
	<!-- End Common Doc -->
</body>
</html>
